This commit reworks `src/DataWrangling/` along two related axes:

1. JRA55 is no longer a special-case data source. The bespoke
   `JRA55NetCDFBackend` struct, `JRA55FieldTimeSeries` constructor, and
   `InMemory()` backend support are removed. JRA55 now flows through the
   same `FieldTimeSeries(::Metadata)` / `Field(::Metadatum)` API as
   ECCO4 / EN4 / WOA / GLORYS, with `inpainting = nothing` selecting the
   chunked-yearly NetCDF dispatch path. `JRA55NetCDFBackend(N)` is kept
   as a thin function that returns a `DatasetBackend(N, nothing;
   inpainting=nothing)` so existing call-sites still construct the right
   backend.

2. A new `PrefetchingBackend{B<:DatasetBackend}` wraps any
   `DatasetBackend` and hides the next sliding-window's I/O behind the
   current window's compute via `Threads.@spawn`. Opt in via
   `prefetch=true` on `FieldTimeSeries(::Metadata)`,
   `DatasetRestoring(...)`, or `JRA55PrescribedAtmosphere(...)`.

New / removed
-------------

- New `src/DataWrangling/dataset_backend.jl`: the existing
  `DatasetBackend{N,C,I,M}` extracted from
  `metadata_field_time_series.jl`, plus its constructors / accessors
  and the generic per-file `set!` used by ECCO4 / EN4 / WOA.
- New `src/DataWrangling/prefetching_backend.jl`: the
  `PrefetchingBackend` wrapper, hot/cold-path `set!`, cyclical-wrap
  scheduling, property forwarding so `fts.backend.start` etc. continue
  to address the inner `DatasetBackend`.
- New `retrieve_data(::JRA55Metadatum)` (split per dataset type to
  handle the no-leap calendar issue in multi-year files; see below) so
  that the generic `Field(::Metadatum)` path produces a correct 2D
  slice for any JRA55 metadatum.
- Removed `JRA55FieldTimeSeries`, the `JRA55NetCDFBackend` struct, and
  the JRA55-specific `Adapt.adapt_structure`.
- Updated tests and examples to the new pattern.

Net diff: +487 / −403.

Closes #18.

----

Background — why this matters
-----------------------------

OMIP simulations on the ORCA grid surfaced periodic wall-time spikes
during time stepping:

```
[ Info: iteration: 133680, wall time: 1.780 seconds
[ Info: iteration: 133690, wall time: 23.906 seconds   <-- spike
[ Info: iteration: 133700, wall time: 1.732 seconds
```

Two causes were identified on `ss/omip-prototype`:

1. `set!(fts::JRA55NetCDFFTSMultipleYears)` was opening every yearly
   NetCDF file in the metadata (~60 for the full 1958–2019 atmosphere)
   per reload, even files with no overlap with the current window.
   This added up to ~660 NetCDF opens per reload across 11 atmospheric
   variables.

2. The remaining ~15 s spike (down from ~24 s after fix 1) is the
   actual cost of reading ~2 GB of compressed NetCDF across 11 files,
   and cannot be reduced further without either shrinking the window
   (more frequent spikes) or hiding the I/O behind compute.

On the 1° configuration, this manifests roughly as **~35 s per reload
on the cold path** and **~15 s on the hot path** (after staging files
to fast scratch and applying the per-window file filtering from
`ss/omip-prototype`). Across a year of simulation that is a few percent
of total wall time, dominated by I/O serialised against the time step.

The first fix (per-window filename filtering + per-file `ftsn_loc`) is
ported here as a plain bug fix. The second is what motivates the
`PrefetchingBackend`.

How prefetching works
---------------------

A `PrefetchingBackend` carries an inner `DatasetBackend` plus three
mutable fields: a `Task`, a buffer `FieldTimeSeries` (a clone of the
main FTS whose `data` array is the prefetch destination), and the
absolute `next_start` index that the buffer will hold once its task
completes.

When Oceananigans calls `set!(fts)` after advancing the window:

1. If the pending prefetch's `next_start` matches the requested
   `start`, `wait(task)` (typically a no-op because the read finished
   while the time step was running) then
   `copyto!(parent(fts.data), parent(buffer_fts.data))` — a memory copy.
2. Otherwise — the cold path on first reload, on checkpointer restart,
   or after an unexpected window jump — drain any stale task,
   synchronously load via a one-off clone FTS, then copy.
3. Either way, schedule the next window's load:
   `Threads.@Spawn set!(next_buffer_fts)` with the inner backend
   re-pointed at `mod1(start + length, length(fts.times))`.

The clone-FTS approach (rather than swapping `fts.backend` to the inner
DatasetBackend in place) keeps the type of `fts.backend` stable across
reloads and lets the spawned `set!` dispatch through the existing
JRA55-specific methods without any special-casing.

JRA55 calendar caveat (multi-year)
----------------------------------

JRA55 NetCDF files use a `DateTimeNoLeap` (365-day) calendar internally,
while `all_dates(::MultiYearJRA55, name)` is a `Dates.DateTime` step
range that includes Feb 29 of leap years. `retrieve_data` is therefore
split: `retrieve_data(::RepeatYearJRA55Metadatum)` uses position-based
indexing (safe — repeat year 1990 is itself non-leap), while
`retrieve_data(::MultiYearJRA55Metadatum)` reads the file's time axis
and matches by `(Y, M, D, H, min)` components, sidestepping the
calendar mismatch entirely. A pre-existing analogous bug in
`set!(::JRA55NetCDFFTSMultipleYears)` (`file_times` and `fts.times`
diverge across leap years) is **not** addressed here — flag for a
follow-up issue.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…efetch